BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / msgtos20.zip / MSGCFG.DOC < prev next >

Wrap

Text File | 1992-02-11 | 67KB | 1,915 lines

MSGTOSS Version 2.0 High-Performance FidoNet Mail Processor for RBBS-PC Copyright(c) 1989-92, Mike Zakharoff & Warren Muldrow Mike : FidoNet 1:138/154 Rbbsnet 8:918/10 Warren: FidoNet 1:3617/1 Rbbsnet 8:928/1 ALL RIGHTS RESERVED R E F E R E N C E M A N U A L for MSGTOSS.CFG Written by Mike Zakharoff MSGTOSS.CFG contains system-related parameters which affect all aspects of MSGTOSS operation. These entries include such entries as file/paths en- tries, multi-tasking/LAN related parameters, and other items that affect MSGTOSS in a global manner. For description purposes, all entries in the MSGTOSS.CFG are referred to as "parameters" in this and other MSGTOSS document(s). DISCLAIMER ---------- The authors make no claims or warranties with respect to the contents or accuracy of this publication, or the product it describes, including any warranties of fitness or merchantability for a particular purpose. Any stated or expressed warranties are in lieu of all obligations or liability for any damages, whether special, indirect, or consequential, arising out of or in connection with the use of this publication or the product it describes. Furthermore, the right is reserved to make any changes to this publication without obligation to notify any person of such changes. MSGTOSS.CFG Reference Manual L I C E N S E ------------- MSGTOSS is not a Public Domain program and is not free. MSGTOSS is copyright(c) 1989,1990,1991,1992 by Mike Zakharoff and Warren Muldrow. Non-registered users of this program are granted a two week license to evaluate the program suitability for their requirements. Any usage of Msgtoss beyond evaluation time period requires registration. Use of non- registered copies of Msgtoss beyond the original evaluation period is not wished. You are free to distribute the PUBLICLY AVAILABLE shareware version of MSGTOSS. MSGTOSS is SHAREWARE. MSGTOSS was not an easy project, as it took 1000's of hours to develop and test. The author has written other RBBS utilities such as MSGRENUM, MAILWAIT, MSGECHO, FIXMSG, all of which were released as freeware; none of which compares to the complexity of MSGTOSS. Fu- ture releases of MSGTOSS will depend upon how much support the author re- ceives. Therefore the author is asking for $25.00 for its use to: MIKE ZAKHAROFF 18004 22ND ST CT E SUMNER, WA 98390 Keep in mind that the authors could have easily crippled MSGTOSS with all sorts of schemes, including disabling the multi-tasking/network support, requiring a password, annoying "not-registered" lines appended to the tear line, beg screens, long delays, and other things to pester you to support the authors. If I were to figure out the amount of hours it took to devel- op and test this program, it would easily run into 10,000 hours of personal time that really can't be assigned any value. This was a service to the RBBS-PC community, and its development will set the stage for RBBS-PC's fu- ture in the Fidonet comminity. Cards and letters always welcome! Registered users will receive a personal registration code (See REGCODE in MSGCFG.DOC), and as much personal support as possible. Non-supporters will basically be doomed to slither in their own guilt for all eternity. WARRANTIES ---------- MSGTOSS is guaranteed only to occupy space on your hard drive. Therefore the use of MSGTOSS is solely at your own risk! MSGTOSS had been beta tested extensively to eliminate bugs, however due to the limitless pos- sibilities of system configurations, no warranty is possible. Also, there are no guarantees that the author will upgrade MSGTOSS. TRADEMARKS ---------- The following products are mentioned in this documentation: Binkleyterm,Desqview,Frontdoor,Lharc,Makearc,Ommm,Qmail,RBBS-PC & Spaz Page - 2 MSGTOSS.CFG Reference Manual TABLE OF CONTENTS ----------------- Page Network Address Parameters................................ 5 ZONETYPE----> Amount of zone tightness ................ 5 DOMAIN------> Location of Nodelists ................... 5 NODE--------> Full 5d Zone:Net/Node address ........... 5 POINTNET----> Point net address for NODE .............. 7 REMAP-------> Users to be remapped .................... 7 Mail and File Forwarding authorizations................... 8 MAILFROM----> RouteMail authorizations ................ 8 MAILTO------> RouteMail authorizations ................ 8 FILEFROM----> RouteFile authorizations ................ 8 FILETO------> RouteFile authorizations ................ 8 KILLNULL----> Kill null messages (Y/N) ................ 9 Maximum Messages Exported during /FEED ................... 10 PACKERCMD---> Cmd to pack up mail for HUBS ............ 10 Sysop Names Parameters.................................... 11 SYSALIAS----> Secret name of sysop .................... 11 SYSNAME-----> Common names of sysop ................... 11 Packet Unarchiving & SPAZ Information..................... 13 SPAZ INFO Text on how to use SPAZ ................ 13 PKTWILD-----> Fido packet extensions .................. 13 Miscellaneous directories................................. 14 FILES-------> Where MSGTOSS looks for mail/files ...... 14 OUTBOUND----> Where *.OUT files are built ............. 14 WORKDIR-----> RAM disk directory for faster I/O ....... 15 LOGDIR------> Where MSGTOSS.LOG is written ............ 15 Two important RBBS message bases.......................... 16 MESSAGES----> Main RBBS message base .................. 16 BLANKMSG----> Blank message base used for auto-repair . 16 RBBS message base parameters.............................. 17 RBBS-MAX----> RBBS maximum messages setting ........... 17 ELASTIC-----> Support ELASTIC message bases ........... 17 MSGMULT-----> Method to calculate max-messages ........ 17 KILLOVER----> Ignore RBBS messages over this size ..... 18 NETBIOS, DESQVIEW, PC-NET & 10-NET........................ 19 LOCKTYPE----> Method of file locking .................. 19 LOCKWAIT----> Seconds to wait after un-locking ........ 19 LOCKTIME----> Max seconds before forcing un-lock ...... 19 Page - 3 MSGTOSS.CFG Reference Manual TABLE OF CONTENTS (Cont.) ----------------- Page RBBS purging related parameters........................... 21 MAINT%LO----> Min % capacity when purge is required ... 21 MAINT%HI----> Max % capacity before purge is required . 21 DAYSTOSYS---> Sysop messages age before auto-kill ..... 22 DAYSFRSYS---> Sysop messages age before auto-kill ..... 22 DELREADSYS--> Sysop auto-kill message if read ......... 22 DAYSTOUSR---> User messages age before auto-kill ..... 22 DAYSFRUSR---> User messages age before auto-kill ..... 22 DELREADUSR--> User auto-kill message is read ......... 22 YEAR--------> Current calander year ................... 22 FIXMSGCMD---> Cmd to repair corrupt message bases ..... 23 Duplicate checking related stuff.......................... 24 DUPFILE-----> Database of EID codes ................... 24 MAXAREAS----> Reserves spaces in EID database ......... 24 DUPSIZE-----> Number of messages to dup check ......... 24 Wait for users to go off-line............................. 25 CONFWAIT----> Minutes to wait ......................... 25 Words used for message "capturing"........................ 26 CAPTURE-----> Colorful metaphors to capture ........... 26 Strip lines beginning with "text"......................... 28 SECL--------> Text to strip lines ..................... 28 Miscellaneous Stuff....................................... 29 UTIL1-------> File to place UTIL1CMD data ............. 29 UTIL1CMD----> Misc utility commands ................... 29 UTIL2-------> File to place UTIL2CMD data ............. 29 UTIL2CMD----> Misc utility commands ................... 29 REGCODE-----> Registration code ....................... 29 INDEX (See MSGIDX.DOC).................................... <- Page - 4 MSGTOSS.CFG Reference Manual Network Address Parameters -------------------------- ZONETYPE - Either "1", "2" or "3". Example: ZONETYPE---->2 1) Common UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU areas for all zones and domains. 2) Separate UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU areas for each unique domain. All zones within a do- main share the same areas. 3) Separate UNKNOWN, MSGCAPTURE, NETMAIL and ROUTETHRU ar- eas for all zones/domains. ---------------------------------------------------------------------- DOMAIN - Identifies all of the domains to which you belong, the de- fault zone number for that domain, and the directory and file name of the St. Louis format (raw, uncompiled) node list(s) for that domain. If a file extension is not spec- ified, MsgToss will look for the newest node list with that name when it compiles the node list data (see the /NLST command line switch). The domain statement and a compiled nodelist is required if you use more than a sin- gle domain or zone. Example: DOMAIN------>fidonet.org 1 C:\MAIL\NODELIST\nodelist DOMAIN------>rbbs-net.org 8 C:\MAIL\NODELIST\rbbslist NOTE: The /NLST switch calls the MSGNLST.EXE program, which creates a MSGTOSS (only) binary nodelist called MSGTOSS.NOD in the default directory. ----------------------------------------------------------------------- NODE - Full "5 dimensional" address of all FidoNet compatible AKA's. [zone]:[net]/[node].[point]@[domain] ^ ^ ^ ^ These are required! Example: NODE-------->1:343/36.0@fidonet NODE-------->8:918/0.0@rbbs-net NODE-------->30:333/66.0@eggnet MSGTOSS expects a ":/.@" to be in this entry. The "36.0" indicates that you are NOT a point of another... if you are, then enter your point number as "36.2" if you are the Page - 5 MSGTOSS.CFG Reference Manual second point of someone else... Normally, this would just be "36.0". NOTE: The ZONE of the FIRST node listed is the DEFAULT ZONE! NOTE: The order of the NODE--------> entries must coincide with the "NODE:x" entries in your MSGTOSS.BBS file (very important!) NOTE: You can have up to 10 NET/NODES NOTE: The @domain must match to one of your DOMAIN------> statements!! NOTE: Your FIRST node entry should be your DEFAULT domain NOTE: If you have multiple NODE--------> entries within the same domain (like 1:343/1, 1:343/0, 1:343/2) then you MUST list the node entry which you want to appear in your * Origin: line FIRST. Example: You are a HUB and you are 1:343/0,1 & 2... You DON'T want 1:343/0 to appear in the * Origin: line, so you would enter the following: NODE-------->1:343/1.0@fidonet (* Origin line) NODE-------->1:343/2.0@fidonet NODE-------->1:343/0.0@fidonet ****************************** IMPORTANT!! **************************** * The NODE--------> entries MUST coincide with the "NODE:x" entries * * in your MSGTOSS.BBS file. For instance, if your FIRST NODE entry * * is: * * * * NODE------->1:343/36.0@fidonet * * * * Then you must have a NODE:1 ("1" meaning your FIRST NODE--------> * * entry) which informs MSGTOSS that these conferences (MSGTOSS.BBS) * * are associated with this NODE-------> entry. * * * * NOTE: Failure to set these correct will screw up the * Origin: * * lines during an export! * * * * NOTE: Once you configure a NODE-------> entry to a corresponding * * NODE:x entry (MSGTOSS.BBS) you shouldn't change the ORDER * * of the NODE--------> entries unless you simultaneously * * change the order of the NODE:x entries. * * * * Remember, remember, remember... These two items (NODE-------> & * * NODE:x) are linked and MUST be configured properly. * * * * Confused? See the sample MSGTOSS.CFG and MSGTOSS.BBS files and * * notice how NODE:1 corresponds to NODE-------->1:343/36.0@fidonet * * and NODE:2 corresponds to NODE-------->8:918/10.0@rbbs-net. * * * Page - 6 MSGTOSS.CFG Reference Manual * Also see documentation on the MSGTOSS.BBS NODE:x entry. * * * *********************************************************************** ----------------------------------------------------------------------- POINTNET - Your private "point" network. MSGTOSS will strip outgoing point addresses before being transmitted to main host. Will add a "FMPT x" to all mail from points. Will re-ad- dress NETMAIL addressed to main system to the point IAW the "TOPT x" entry that should be in the incoming NETMAIL point mail. Each defined NODE address can have a differ- ent point network. The POINTNET line must follow the NODE address to which it belongs NOTE: The order of this entry must coincide with a NODE--------> entry. For instance: NODE-------->1:343/36.0@fidonet POINTNET---->30174 Because 30174 follows 1:343/36, therefore it MUST be a point address of it. If you add a POINTNET entry before a NODE entry, MSGTOSS will complain about it. ----------------------------------------------------------------------- REMAP - Remaps mail to POINT addresses when a message does NOT contain a valid "TOPT x" entry. The REMAP lines must follow the POINTNET line to which they belong. ------>[Point Number](space)[First Last] Example: NODE------->1:343/36.0@fidonet POINTNET--->30174 REMAP------>1 Rich Englich Any NETMAIL that is received for "Rich Englich" will be re-mapped to address 1:30174/1. NOTE: The order of this entry must coincide with a POINTNET---> entry. For instance: Because 30174 follows 1:343/36, therefore it MUST be a pointnet address of it. Since REMAP 1 follows POINTNET 30174, then 1:30174/1 must be Rich Englich. If you add a REMAP entry before a POINTNET entry, MSGTOSS will complain about it. ----------------------------------------------------------------------- Page - 7 MSGTOSS.CFG Reference Manual Mail and File Forwarding authorizations --------------------------------------- MAILFROM - Nodes FROM which mail will be routed MAILTO - Nodes TO which mail will be routed FILEFROM - Nodes FROM which files will be routed FILETO - Nodes TO which files will be routed The MAILFROM and MAILTO options control routing of net mail. Mail addressed to another system which is received from a node listed (or not excluded) in the MAILFROM line will be forwarded. Also mail addressed to any system listed (or not excluded) in the MAILTO line will be for- warded. Extreme Example: MAILFROM---->1:*/* 8:*/* This means that MSGTOSS will route (send) mail anywhere, regardless of where the destination is, as long as the originator (MAILFROM) resides in Zone 1 or Zone 8, any Net/Node. This is NOT a good idea (unless you have an ar- ea called ROUTETHRU). MAILTO------>1:*/* 8:*/* This means that MSGTOSS will route (send) mail anywhere, regardless of where the destination is, regardless of who sent it, as long as the destination (MAILTO) resides in Zone 1 or Zone 8, any Net/Node. This is also NOT a good idea (unless you have an area called ROUTETHRU). Confused? Consider this: MAILFROM---->1:343/-5 -10 * This means that MSGTOSS will route (send) mail anywhere, regardless of where the destination is, as long as the originator (MAILFROM) resides in Zone 1, net 343, except for 1:343/5 and 1:343/10 (looks like they abused routing privileges and were locked out). NOTE: Note that the '*' at the end of the line means (in this case) "all the rest". Consider: MAILTO------>1:343/* 8:918/* This means that MSGTOSS will route mail from anyone, as long as the destination is any node within Zone 1, net 343 or Zone 8, net 918. Zone:Net/Node Syntax: Page - 8 MSGTOSS.CFG Reference Manual '*' is a wild card for "all" or "all the rest" '-' means to exclude. Realtime example: 1:343/* 918/1 666/-1 -45 -36 -66 * Means zone 1, anyone in NET343, 918/1 and anyone in NET666 except nodes 1,45,36, & 66 REMEMBER! Don't confuse "." with "/".... "1:343.*" is not the same as "1:343/*"! The FILETO and FILEFROM lines work exactly the same as MAILFROM and MAILTO, but are used for messages with the "file attach" flag set. The first FILES statement in your MSGTOSS.CFG will be used to rebuild the path to the file named in the subject line of the message so your mail packer will be able to find the file to be sent. If the above authorization fails, then the "HOLD" bit is set on the routed message. Note that yet another layer of security exists where is you use the special area called "ROUTETHRU", then ALL routed mail (regardless) will be sent there and the above authorization scheme still applies.... Example: You set MAILFROM, TO FILEFROM,TO to simply.. "*:/*", which means ALL authorized, for ALL zones, for ALL nets.. If you have an area called ROUTETHRU, then everything not addressed to your system will go there.. As long as you DON'T scan the area (normally), you can simply "move" the message into a NETMAIL area, and it (poof) becomes active (and authorized). ----------------------------------------------------------------------- KILLNULL - Kill null messages (Y/N). If this parameter set to 'Y', MSGTOSS will kill null messages that don't contain text within its body. These types of messages are usually gen- erated by file-attach type mailers, used to send mail or files. MSGTOSS will (as it kills a null message) log its occurace into a file called MSGTOSS.NUL, which contains the date, packet, message number, AREA (if present), and the message header for analysis. MSGTOSS.NUL should be viewed on occasion. Example: KILLNULL---->Y ----------------------------------------------------------------------- Page - 9 MSGTOSS.CFG Reference Manual Maximum Messages Exported during /FEED (/FMAX:xxx) -------------------------------------- PACKERCMD - For HUBS, when doing a /FEED, MSGTOSS will either exit processing or SHELL out to a packer when /FMAX:xxx messages have been exported. For instance: Example: PACKERCMD--->QMAIL -PACK --or-- PACKERCMD--->OMMM --or-- PACKERCMD--->MAKEARC And "/FMAX:1000" as a switch: MSGTOSS will, after exporting 1000 messages (in any combi- nation to any set of nodes), and done with the current PKT file, close ALL *.OUT files, and SHELL out to PACKERCMD. When done, will return back, re-open *.OUT files, and con- tinue on. However, this requires GOBS of memory, as you all know how big MSGTOSS is. It seems to work fine with 570K and OMMM 1.52. Here is a memory saving (but slower) alternate: Make PACKERCMD---> equal to "" (blank) and use the /FMAX:xxx switch. MSGTOSS will then gracefully exit, closing all *.OUT files, mailwaiting, etc. You can then execute your packer. Then check existence of *.PKT files, and if present re-execute MSGTOSS. For instance: :DOIT MSGTOSS /TOSS/FEED/FMAX:1000 (PACKERCMD----> = "") QMAIL -PACK If exist F:\FILES\*.PKT Goto DOIT Looping endlessly till all *.PKTS are gone, but is slight- ly slower. Recommended to use a SMALL packer (like Ommm 1.52 or Make- ARC) vice QMAIL -PACK, as they take up alot less overhead (memory). But you can try it. NOTE: If you DON'T want MSGTOSS to SHELL, then make PACKERCMD---> blank! Otherwise, MSGTOSS will simply shell out. Even if you run out of memory, MSGTOSS should recover gracefully, as it will simply re-open the *.OUT files for append. NOTE: The PACKERCMD----> is likely to go away in the future when MSGTOSS gets its own packer. ----------------------------------------------------------------------- Page - 10 MSGTOSS.CFG Reference Manual Sysop Names Parameters ---------------------- SYSALIAS - The SYSALIAS parameter tells MSGTOSS which user name is considered the SYSOP. This should be the same name as was entered in CONFIG for the secret remote logon, and for LOCAL logon (ESC switch). Any messages that match those as specified by the various SYSNAME(s) will cause the mailwaiting bit for the SYSALIAS user to be set, and cause the TO: field to be changed to the text 'SYSOP', if 'SYSOP' is not already part of the TO: field. NOTE: MSGTOSS requires that the SYSALIAS exist in all of the conferences, or a non-fatal error message is displayed, irritating you until you add it. ----------------------------------------------------------------------- SYSNAME - This parameter controls what messages are considered the SYSOP. This is used during the EXPORTING, PURGING, and MAILWAITING phases of the MSGTOSS. MSGTOSS will set the SYSOP's mailwaiting bit ONLY if the message matches the below criteria, and will be exempt from purging as well until killed. The FIRST CHARACTER must be either a '!' or a '=', nothing else is allowed. The '!' means CONTAINS and the '=' means EXACT. !SYSOP keep messages that contain the string 'SYSOP' (Not recommended, as every message to 'JOE SYSOP' will set the mailwaiting bit for the SYSALIAS user (sysop). =SYSOP will match on messages that ONLY have 'SYSOP' in TO/FROM, will set the mailwaiting bits, and be exempt from purging until either killed by the sysop, or DAYS(s) parameters apply. !LASTNAME incase a message 'MIKE ZAKHAROFF @ 343/36' !SYSOP @343/36 is also recommended or just '!SYSOP @' Read! --> NOTE: During an EXPORT from an RBBS message base, MSGTOSS use the FIRST "SYSNAME" entry and use that as the common name for all messages that originated "FROM" the sysop. Basically, this means to make your FIRST entry your REAL name, like: SYSNAME---->=MIKE ZAKHAROFF NOTE: During the MAILWAITING processing, MSGTOSS will convert messages addressed to your SYSNAMES to 'SYSOP', if SYSOP is not already part of the 'TO:' name, and set the mailwaiting bit for the user you entered under the SYSALIAS parameter. Example: A message arrives to 'MIKE ZAKHAROFF'. Because a SYSNAME is '=MIKE ZAKHAROFF' that message Page - 11 MSGTOSS.CFG Reference Manual will be converted to 'SYSOP' in the TO:Field. Example:A message arrives to 'JOE SYSOP' and '=SYSOP' is only entered as a SYSNAME. That message will be treated as if it is another junk message, and MSGTOSS will purge it whenever it thinks it need to and will NOT set the sysops mailwaiting bit. NOTE: ANY message addressed to your SYSNAMES(s) will cause the mailwaiting bit to be set for the user as specified by your SYSALIAS! NOTE: You can have up to 10 SYSNAME(s) ----------------------------------------------------------------------- Page - 12 MSGTOSS.CFG Reference Manual Packet Unarchiving & SPAZ Information ------------------------------------- SPAZ INFO - Command to issue to unarchive mail packets. Recommended to use only SPAZ.COM, because it can handle ZIP, LHARC, ARC etc. SPAZ -F C:\MAIL\FILES C:\MAIL\FILES\ ------------- ---------------------------- Incoming Mail Where PKTS go for processing NOTE!! --> Where trailing back-slashes are! NOTE: MSGTOSS looks in the directory(s) specified by the FILES-------> parameter(s) for PKTs. Therefore, the "C:\MAIL\FILES\" SHOULD match the FILES-----> entry. NOTE: Place the SPAZ command in your batch file PRIOR to executing MSGTOSS. Here is an example... :RECMAIL SPAZ -F -O C:\MAIL\FILES C:\MAIL\FILES\ If Exist C:\MAIL\FILES\*.pkt Goto TOSSIT If Exist C:\MAIL\FILES\*.?ut Goto TOSSIT Goto START :TOSSIT Msgtoss /TOSS/PREP/FIXC/NSTOP If Exist Msgclean.bat Call Msgclean.bat Goto START ----------------------------------------------------------------------- PKTWILD - Wildcards of what extentions FIDO Packets can be. This is useful if you do creative re-naming of *.PKT(s) and you want MSGTOSS to ONLY recognize *.PKT that have an exten- tion like maybe "*.ZAK" <grin>. So you just change this parameter to "*.ZAK" and MSGTOSS will ignore other exist- ing *.PKT files. Example: PKTWILD----->*.PKT *.?UT ----------------------------------------------------------------------- Page - 13 MSGTOSS.CFG Reference Manual Miscellaneous directories ------------------------- FILES - Directory INCOMING mail and files go to FIRST. You can have up to 10 "FILES------>" entries. MSGTOSS will no longer look in the default directory for PKTS. Example: FILES------->C:\FILES\ FILES------->C:\MAIL\FILES\ NOTE: The FIRST entry is considered your default FILES en- try, and should be the same directory as where your mailer sends files. This is important only for file routing services, as MSGTOSS (when attempting to route files) will LOOK for files in this directory. MSGTOSS will look in all of your FILES-------> entries for *.PKT files, as defined in your PKTWILD-----> entries. If you you don't route files, then all that is important is that this directory contains these packets. ----------------------------------------------------------------------- OUTBOUND - The MAIN outbound directory of your default zone (The ZONE that is present in the FIRST "NODE----->" entry. Example: OUTBOUND---->C:\BT\OUT NOTE: MSGTOSS uses the Binkley standard regarding the out- bound directories for each zone. Example: C:\BT\OUT.001\ = Zone 1 directory C:\BT\OUT.008\ = Zone 8 directory NOTE: If default zone is "1" then.... C:\BT\OUT\ = Zone 1 directory C:\BT\OUT.008\ = Zone 8 directory NOTE: If the zone number is greater than 9, then you must use the HEX value of the zone. For instance, zone 15 would be represented as C:\BT\OUT.00F because "F" is HEX 15. Don't worry too much about this, as MSGTOSS will look for the presence of this directory (during a /TEST) and complain that C:\BT\OUT.00F does not exist, prompting you to cre- ate it. NOTE: MSGTOSS will check for the presence of these for EACH UNIQUE zone entered in your "NODES------>" en- tries. READ! ---> However, if you place [DOMAIN] as part of this parameter, MSGTOSS will "dynamically" replace the outbound DOMAIN and use that for the outbound directory. Example: C:\BT\[DOMAIN]\ Page - 14 MSGTOSS.CFG Reference Manual If the outbound domain is "fidonet", MSGTOSS will create the outbound *.OUT file in a directory called "C:\BT\FIDONET\", the same way that Binkleyterm 2.4+ uses. The same rule regarding ".001", ".008" extentions also ap- ply to this. NOTE: For file-attach systems such as FrontDoor, etc. that don't use the Binkley standard, you will need a con- verter utility such as "Makearc" that will archive the *.OUT files that MSGTOSS creates and create a file-attach message. This has been tested and works fine. Makearc is available on most BBS systems. However, you will still need to create the Binkley standard directory structure to make MSGTOSS work properly (sorry). ----------------------------------------------------------------------- WORKDIR - RAM Disk (recommended) where MSGTOSS will COPY the current message base being PURGED. Will check for available space first. Not enough space will cause default directory to be used. Need to specify the "/WDIR" switch to activate. Example: WORKDIR----->F:\TEMP\ Where F:\TEMP\ is hopefully (but not necessarily) a RAM disk. NOTE: This is also used for copying the MSGTOSS.EID data- base for doing duplicate file checking (CDUP:1 key- word) and for building some other temporary files. Even if you have a real SMALL RAM disk, still use the /WDIR, as some of MSGTOSS(s) disk-intensive tasks use small files. If not enough space is available, MSGTOSS will use the default disk (where MSGTOSS is executed). When using the /LOCK switch, MSGTOSS will NOT copy the message base being purged to the RAM disk. ----------------------------------------------------------------------- LOGDIR - Where MSGTOSS will write its MSGTOSS.LOG & MSGTOSS.ERR files. Blank will end up in default directory. Example: LOGDIR------>C:\MSGTOSS\ ----------------------------------------------------------------------- Page - 15 MSGTOSS.CFG Reference Manual Two important RBBS message bases -------------------------------- MESSAGES - Path/FileName of Main RBBS Message Base. This is used for the /WAITxx and /LOCK related switches. MSGTOSS needs to know what directory to write the NETBIOS file "IBMFILES". For /WAIT, MSGTOSS will monitor the "node" records until all users are off-line. Example: MESSAGES---->C:\RBBS\MESSAGES -- or -- MESSAGES---->C:\RBBS\MAINM.DEF In addition, when using the "/MUSER:xx" switch (see docs) MSGTOSS uses this information to determine which message base (the main one) to which to modify the nodes records when MSGTOSS becomes an active "user" on-line. NOTE: See MSGSWI.DOC for more information on /MUSER:x MSGTOSS also uses the "user count" field of the main mess- age base to determine how much memory is required during purging and mailwaiting operations. ----------------------------------------------------------------------- BLANKMSG - A "model" message base (un-corrupt, small) that will be used with the "/FIXC" command line. If FIXMSG fails twice then the message base entered here will be copied over the original (corrupt) message base. The corrupt message base will be renamed *.BAD. This insures that MSGTOSS will never abort due to a corrupt message base (which it doesn't tolerate). This occurring will be entered into the MSGTOSS.LOG file. Example: BLANKMSG---->C:\RBBS\BLANKM.DEF ----------------------------------------------------------------------- Page - 16 MSGTOSS.CFG Reference Manual RBBS message base parameters ---------------------------- RBBS-MAX - Reflects the current RBBS-PC maximum messages. The maximum of 999 may soon change to 9999, so this is why the RBBS-MAX----> parameter is present in the MSGTOSS.CFG file. The default entry is 999, which reflects the current RBBS-PC maximum. In the event the maximum is raised (future releases of RBBS-PC) the MSGTOSS RBBS-MAX---> parameter will have to be adjusted. Example: RBBS-MAX---->999 NOTE: Some clever RBBS-PC programmers have been able to make code changes to RBBS-PC to increase the MAX-MESSAGES to over 2000, if you do this, then also increase RBBS-MAX to that value. ----------------------------------------------------------------------- ELASTIC - Either "YES" or "NO". This is designed to support the new "elastic message bases" of RBBS-PC. What this actually does is tell MSGTOSS to make the "maximum messages" value that is present in the message base "checkpoint record" to be the value of the "RBBS-MAX--->" parameter, no matter what MSGTOSS calculates it to be normally. Example: ELASTIC----->NO NOTE: You can still use the "/PREP" switch, even though you set ELASTIC to "YES". MSGTOSS will still CHOP the message bases back down to the "RECS:xxxx" values set in the MSGTOSS.BBS file. NOTE: If you set ELASTIC-----> to "YES" it is recommended that you set MAINT%LO----> and MAINT%HI----> to both 100(%). ----------------------------------------------------------------------- MSGMULT - What scheme MSGTOSS is going to use when setting the "Max messages" of an RBBS conference. Setting to blank or "5" will use regular RBBS standards. Valid entries are 2-5. Example: MSGMULT----->5 During the normal operation of MSGTOSS (purging, expanding, setting mailwaiting bits, etc.) MSGTOSS is constantly resetting the 'Max Messages' value entered in the message bases 'Checkpoint Record'. Normally, you set this value via CONFIG, but MSGTOSS will change it whenever it requires. RBBS assumes that the 'Max Messages' value Page - 17 MSGTOSS.CFG Reference Manual is set APPROXIMATELY to "TOTAL.MESSAGE.RECORDS / 5". Message records = 1000 - Max Messages = 200 (1000/5) Message records = 2000 - Max Messages = 400 (2000/5) This is normally not a problem, but with the introduction of the SECL--------> entries it is possible for MSGTOSS to import more messages in a given message base than the default 'Max Messages' value. Basically this means that even though there is PLENTY of room for a newly en- tered message (by a user), if the 'Max Messages' entry exceeds the number of messages, the user will be pres- ented with "Not enough room for new messages, try again tomorrow". This has been kludged with MSGMULT-----> parameter, where you can tell MSGTOSS what multiplier to use (default is 5) while setting the 'Max Messages' value. The multi- plier can be anywhere between 2 and 5. MSGMULT:5 Records = 1000 - Max Messages = 200 (1000/5) MSGMULT:4 Records = 1000 - Max Messages = 250 (1000/4) MSGMULT:3 Records = 1000 - Max Messages = 333 (1000/3) MSGMULT:2 Records = 1000 - Max Messages = 500 (1000/2) Basically, leave it at 5 unless you have problems. ----------------------------------------------------------------------- KILLOVER - Prevent TOSSING (ignore) of any message over this size. Example: KILLOVER---->32000 When tossing to *M.DEF files, MSGTOSS will ignore messages over this size. If you want all messages imported, set to 32000. This only applies to *M.DEF and not a Fido (*.MSG) area. ----------------------------------------------------------------------- Page - 18 MSGTOSS.CFG Reference Manual NETBIOS, DESQVIEW, PC-NET & 10-NET record locking (/LOCK) ------------------------------------------------- LOCKTYPE - Either "NETBIOS", "DESQVIEW", "PC-NET", "10-NET" or "". This directs which type of file/record-locking procedure is used when used in a multi-user environment. To acti- vate this feature, specify "/LOCK" on the MSGTOSS command line. Allows tossing to M.DEFs while users are on-line. Example: LOCKTYPE---->NETBIOS MSGTOSS will attempt to detect the presence of NETBIOS and/or DESQVIEW, but does not attempt to detect PC-NET or 10-NET. If either of these are specified, MSGTOSS will assume their presence and use their file/record locking procedures. If using NETBIOS, then SHARE.EXE (or equivalent) must be loaded. Most Local Area Networks (LAN) load SHARE as part of their initialization procedure. ----------------------------------------------------------------------- LOCKWAIT - How many seconds MSGTOSS is to wait AFTER it unlocks a message or user base, to allow other nodes a chance to lock the message and enter messages/what ever. Basically MSGTOSS is so fast that after it releases a message base after tossing it will immediately re-lock it to continue tossing. This is designed to slow it down a tad. An en- try of "0" will cause no delay, and entry of ".1" will tell MSGTOSS to wait 1/10 th of a second after un-locking. Example: LOCKWAIT---->.1 NOTE: If you run LOTS of nodes, then you may want to set this higher as the number of nodes are increased. Each increment will slow down MSGTOSS progressively. If you run 20 nodes, and two people are writing mes- sages, and you set LOCKWAIT---->0, then MSGTOSS will probably not relinquish control of the message bases to allow these users to save their messages. ----------------------------------------------------------------------- LOCKTIME - How many seconds MSGTOSS is allowed to keep the message based locked for any period of time. If locked for a time exceeding this value, MSGTOSS unlock the message base, wait for LOCKWAIT seconds, re-load checkpoint data, and then continue. Example: LOCKTIME---->5 Page - 19 MSGTOSS.CFG Reference Manual Means MSGTOSS can only lock the message base for a MAX of 5 seconds. Because of the smart purging techniques MSGTOSS uses, sometimes a message base will be purging for a long time. This will insure that a user will only have to wait a MAX of 5 seconds if trying to save a message while MSGTOSS is working in the background. ----------------------------------------------------------------------- Page - 20 MSGTOSS.CFG Reference Manual RBBS purging related parameters (/PREP) ------------------------------- MAINT%LO - When a purge is required, what % capacity to purge to. MAINT%HI - What is the MAXIMUM % capacity before a purge is required. If using the /PREP (pre-purging) switch, MSGTOSS will es- timate how many message base records are required to be purged to accommodate the new in-coming messages. MSGTOSS will (whenever a purge is called) make sure the message base is around MAINT%LO full after the message bases are tossed. Therefore, if you use /PREP and you have set the following: MAINT%LO---->85 MAINT%HI---->95 And RECS:1000 is set for the message base (via MSGTOSS.BBS) then you can expect that 850 records will contain actual messages, with 150 records of slack (empty records) to accommodate new messages entered by users. Also, whenever a /SIZE (chop message bases) operation is called, MSGTOSS will purge the message bases so that the number of records are MAINT%HI (%) of the value of the "RECS:xxxx" value in the MSGTOSS.BBS file for that confer- ence. NOTE: These two parameters control the purging activity of MSGTOSS. MSGTOSS will automatically maintain the percent capacity of all messages bases somewhere BE- TWEEN these two values. Make sure MAINT%HI is a larger value of MAINT%LO, and that they do not ex- ceed a value of 100 each. Its desirable to have some distance between these two val- ues, like 95 & 85, as if you try to place them too close, then MSGTOSS will call a purge excessively, even though few messages have been received. For instance... You receive a mere 2 messages in a con- ference, and MAINT%() is set to 94 & 95. MSGTOSS will probably have to do a purge on the message base. However, if you wisely set these to 85 & 95, then theres probably ALREADY 10 % free records avail to accommodate those 2 messages, so MSGTOSS will simply append them to the end. As long as the append doesn't violate the MAINT%HI value, then a purge is not required. If you have LARGE message bases, then the ideal setting for is probably 70% and 95%. This way, whenever the mes- sage bases exceeded 95% capacity, MSGTOSS will purge to 70% capacity, and another purge will probably not be re- quired for multiple mail sessions because of the 25% slack. Page - 21 MSGTOSS.CFG Reference Manual ----------------------------------------------------------------------- DAYSTOSYS - Applies ONLY to messages TO the SYSOP: How many days old the message is before it will be KILLED automatically. Example: DAYSTOSYS--->60 ----------------------------------------------------------------------- DAYSFRSYS - Applies ONLY to messages FROM the SYSOP: How many days old the message is before it will be KILLED automatically Example: DAYSFRSYS--->60 ----------------------------------------------------------------------- DELREADSYS - Applies ONLY to messages TO the SYSOP: If the message has been read by the SYSOP, then automatically KILL it, regardless of the setting of DAYSTOSYS parameter. If unread, will remain until the DAYSTOSYS parameter applies. (YES or NO). Example: DELREADSYS-->NO ----------------------------------------------------------------------- DAYSTOUSR - Applies ONLY to messages TO the USERS: How many days old the message is before it will be KILLED automatically. Example: DAYSTOUSR--->30 ----------------------------------------------------------------------- DAYSFRUSR - Applies ONLY to messages FROM the USERS: How many days old the message is before it will be KILLED automatically Example: DAYSFRUSR--->30 ----------------------------------------------------------------------- DELREADUSR - Applies ONLY to messages TO the USERS: If the message has been read by the USER, then automatically KILL it, regardless of the setting of DAYSTOUSRS parameter. If unread, will remain until the DAYSTOUSR parameter applies. (YES or NO). Example: DELREADUSR-->NO ----------------------------------------------------------------------- YEAR - MSGTOSS depends on the SYSTEM CLOCK. If for some reason the system clock YEAR does NOT match the YEAR Parameter, Page - 22 MSGTOSS.CFG Reference Manual MSGTOSS will abort. This is to help prevent the accidental deletion of messages based on the DAYSTO/DAYSFR Parameters by a faulty system clock. Set- ting this parameter to zero will override this check and believe the system clock no matter how wrong it is. Example: YEAR-------->1991 NOTE: Reset this parameter on New Years Day! NOTE: If zero (or blank) then MSGTOSS will assume the sys- tem clock is fine. For safetys sake, it would be best if you use this feature, but right around christmas time set to zero, then sometime after new years re-set it back. ----------------------------------------------------------------------- FIXMSGCMD - Fix [MSGFILE] with this ([USRFILE] available) Example: FIXMSGCMD--->FIXMSG [MSGFILE] When using the /FIX or /FIXC command lines, MSGTOSS will attempt to repair a corrupt message base using this com- mand, dynamically replacing the USER file and MESSAGES file with [USRFILE] and [MSGFILE]. This is a Shell opera- tion, so enough memory must be present to execute the fix- er and return to MSGTOSS. If you don't have FIXMSG, you can do a simple fix by sim- ply entering: FIXMSGCMD--->COPY C:\RBBS\BLANKM.DEF [MSGFILE] Where C:\RBBS\BLANKM.DEF is a small, un-corrupt message base that will be copied over the corrupt message base. Not very practical, but will will work 100% of the time. ----------------------------------------------------------------------- Page - 23 MSGTOSS.CFG Reference Manual Duplicate checking related stuff (CDUP:1 keyword) -------------------------------- DUPFILE - Created by MSGTOSS, Database of EID codes. If using the "/WDIR" (work directory) switch while tossing, MSGTOSS will copy it to/from the ramdisk before and after execut- ing MSGTOSS, as long as sufficient space exists. DUPFILE----->MSGTOSS.EID ----------------------------------------------------------------------- MAXAREAS - Reserves so many spaces in the EID database. Max number of conferences you would EVER have (I have 28, and mine is set for 100, which I would never carry). Each require 32 bytes. MAXAREAS---->100 ----------------------------------------------------------------------- DUPSIZE - The number of previous messages to keep track of in each area of each conference. Basically, the bigger, the slower message processing. If your message bases average 500 messages, then set to at least 500. However, numbers over 1000 are possible. For optimum processing speed, its best to use the /WDIR switch and make WORKDIR----> a RAMDISK for faster processing. MSGTOSS will copy to/from the WORKDIR automatically before/after each MSGTOSS run. Example: DUPSIZE----->500 NOTE: If you have a reliable HUB, who faithfully checks for DUPS before sending to you, then the use of the CDUP:1 keyword may NOT be necessary and will make mail events as fast as possible. These TWO parameters (DUPSIZE and MAXAREAS) determine critical aspects to the MSGTTOSS.EID database. Its infor- mation can be edited/viewed via the supplied MSGTOSS util- ity called MSGEID.EXE. This utility allows you to change things such as MAXAREAS & DUPSIZE, viewing the AREA Index, displaying the number of EID codes present in each area, etc. See MSGSWI.DOC for more information on this. NOTE: Executing with the CDUP:1 keyword the first time will create MSGTOSS.EID. The approximate size of the EID database file can be estimated using the following formula: ((8 * DUPSIZE) * NUMBER.OF.AREAS.YOU.HAVE)) + (MAXAREAS * 32) ----------------------------------------------------------------------- Page - 24 MSGTOSS.CFG Reference Manual Wait for users to go off-line (/WAIT switch) ----------------------------- CONFWAIT - Number of minutes to wait till users are off line (used with the /WAIT switch). Example: CONFWAIT---->10 ----------------------------------------------------------------------- Page - 25 MSGTOSS.CFG Reference Manual Words used for message "capturing" (CAPT:1) ---------------------------------- CAPTURE - Messages that contain the TEXT entered here will be tossed to a special area called "MSGCAPTURE". This area must be located in your MSGTOSS.BBS file. NETMAIL, ROUTEMAIL & UNKNOWN are exempt from capturing. The messages original AREA:xxx tag will be tossed along with the messages. One handy use for this feature is to prevent importing messages that contain foul language into a BBS system, an- other use may be to capture messages from a particular us- er or messages that contain a particular topic. Example: CAPTURE----->SHIT CAPTURE----->FUCK (We're all adults, right) Up to 20 colorful metaphors can be defined Whenever a message contains these words (could be anywhere in the message) then MSGTOSS will divert those messages to a special area defined as MSGCAPTURE. This must be en- tered in your MSGTOSS.BBS file as a non-echo'ed area... Example: -CAPT:1 C:\RBBS\RBBSM.DEF RBBS-PC 1:343/300 -CAPT:0 C:\MAIL\CAPTURE.001 MSGCAPTURE This is entered in your MSGTOSS.BBS file. Then if you have "CAPT:1" turned on for a particular conference (in this example the RBBS-PC conference), then those messages will be diverted to C:\MAIL\CAPTURE.001 as a Fido-style message. Note that you will have to create a separate di- rectory for each unique Zone defined. After to check over these messages, you can re-import these messages to their respective conference via the "/TCAP" (toss captured) com- mand line switch. ******************* WARNING WARNING ********************** * Don't use this feature to censor other BBS systems! * * * * This is intended to censor a private BBS system, for * * those desiring this. A safeguard was built in to * * prevent those who /FEED down-stream nodes from * * capturing messages to down-stream nodes. * ********************************************************** NOTE: To use this feature, you must turn the "CAPT:1" switch on (in your MSGTOSS.BBS file). NOTE: After you are done with the messages in MSGCAPTURE, Page - 26 MSGTOSS.CFG Reference Manual you can re-toss back to the proper area by using the "/TCAP" (toss capture) switch. NOTE: If using /FEED (toss to down-stream nodes while tossing) MSGTOSS will continue to feed the nodes, but the message will be captured "locally". NOTE: If using /TCAP and the /FEED switch, MSGTOSS will NOT feed "captured" messages, as they should have already feed during the first /FEED session. ----------------------------------------------------------------------- Page - 27 MSGTOSS.CFG Reference Manual Strip lines beginning with "text" (SECL:1) --------------------------------- SECL - Using these parameters will DRASTICALLY improve the num- ber of messages allowed to be imported in a given message base, as SEEN-BY: lines can take up incredible amounts of space. This is usually on the order of a 30-40% in- crease of the number of messages allowed in a given mes- sage base. NOTE: The use of this switch creates such an EFFICIENT storage medium for echomail that it is sometimes necessary to INCREASE the 'Maximum Messages' entry on the message base 'Checkpoint Record'. This can be accomplished by the MSGMULT-----> parameter switch. See documentation on this parameter for more information. These parameters are utilized ONLY when the "-SECL:1" is activated in your MSGTOSS.BBS file. This also requires the "-FMAS:1" switch to be active also. These entries de- termine exactly what lines in the RBBS echomail messages (not FIDO) are to be ignored during tossing. Example: You want to strip all occurrences off the "SEEN-BY:" lines in RBBS messages: SECL-------->SEEN-BY: Example: Most echomail control lines begin with a "" so: SECL--------> Will strip EID:, PATH:, MSGID: & VIA: and any other line that begins with an . Example: You ONLY want to strip PATH: and VIA: lines: SECL-------->PATH: SECL-------->VIA: All other lines that begin with an will be imported as normal. NOTE: The most restrictive entry will override a similar less restrictive entry, example: SECL--------> SECL-------->PATH: The first entry ALREADY will strip the second entry! NOTE: Up to 20 "SECL-------->" entries are possible. ----------------------------------------------------------------------- Page - 28 MSGTOSS.CFG Reference Manual Miscellaneous Stuff ------------------- UTIL1 - Batch file or ?? which contains UTIL1CMD commands ----------------------------------------------------------------------- UTIL1CMD - Miscellaneous utility command [MSGFILE], [USRFILE], [AREA] & [WELFILE] available for processing. Example: UTIL1------->UTIL1.BAT UTIL1CMD---->SUBJECT I:[MSGFILE] O:[WELFILE] C:[AREA] And messages were received in the areas RBBS-PC & COMM The above would create a file called UTIL1.BAT that contains the following: SUBJECT I:C:\RBBS\RBBSM.DEF O:C:\RBBS\RBBSW.DEF C:RBBS-PC SUBJECT I:C:\RBBS\COMMM.DEF O:C:\RBBS\COMMW.DEF C:COMM Which you could then execute immediately after MSGTOSS to preform special maintenance or whatever. NOTE: MSGTOSS will delete the UTIL1.BAT (if exist) each time it is run, so execution MUST be done immediately after MSGTOSS exits, or clever batch-file renaming magic can be preformed. ----------------------------------------------------------------------- UTIL2 - Batch file or ?? which contains UTIL2CMD commands See UTIL1-------> details. ----------------------------------------------------------------------- UTIL2CMD - Miscellaneous utility command [MSGFILE], [USRFILE], [AREA] & [WELFILE] available for processing. See UTIL1CMD----> details. ----------------------------------------------------------------------- REGCODE - A twelve-digit registration code. Upon registration, the author will send you this personal code (either by E-Mail or envelope) in which MSGTOSS will recognize you as a per- sonal supporter of MSGTOSS. Note that MSGTOSS is not crippled in any way, and will function with all of its features w/o the REGCODE. During your trial period, set this code to blank (""). Don't worry, there are NO time-bombs in MSGTOSS. Please help support the authors efforts for this fine program. See page two of all MSGTOSS documents for information regard- ing registering MSGTOSS. NOTE: Attempting to use an incorrect code will result in Page - 29 MSGTOSS locking up, and you will have to re-boot.